This invention relates generally to encoding and decoding of data transmitted over data communications networks.
Data to be transmitted over a communications network is commonly encoded in order to improve transmission characteristics, e.g., to improve data recovery rates and/or compress data for higher data transfer rates. In high-speed interconnect technologies such as 10 Gb/s, 40 Gb/s and 100 Gb/s Ethernet, InfiniBand, and 10-, 16- and 20-gigabit fiber channel, data is formatted in 64-bit blocks which undergo various stages of encoding and other processing prior to transmission. For example, an encoding stage employs a rate-64/66 modulation code. This code is a block code with the redundancy of two header bits per 64-bit payload. The 64-bit payload of each 66-bit block is either a control block, containing control information for the transmission process, or a data block containing actual data (i.e. user data, CRC (cyclic redundancy check) data and other “non-control” data). The 2-bit header of the 66-bit block indicates whether the attached payload is a data block or a control block.
The particular format of data and control blocks is defined by the appropriate transmission protocol. In general, different types of control block are defined for use in the system, and each control block includes a dedicated field which indicates the type of that control block. This field, referred to herein as a “block-type field”, may contain one of a predefined set of K bit-patterns each corresponding to a respective one of K different types of control block used in the transmission system. In 100 Gb/s Ethernet, for example, the block format is defined in Ethernet standard IEEE 802.3ba-2010 and is shown in FIG. 1 of the accompanying drawings. The left-hand column of this table indicates the eight data or control “characters” (represented by letters D, C, O, S or T with suffix 0 to 7 denoting position in the block format) of data and control blocks. The rest of the table indicates the 66-bit output block format for the rate 64/66 modulation code. The 66-bit format for data blocks is shown at the top of the table. This starts with the 2-bit sync header 01 indicating that the 64-bit payload is a data block. There are eleven different types of control block in this instance and the 66-bit format for these is as indicated beneath the data block format. In each case this starts with the 2-bit sync header 10 indicating that the 64-bit payload is a control block. The control block commences with an 8-bit block-type field. This contains a bit-pattern representing one of eleven different values, indicated in hexadecimal in the column headed “Block Type Field”, for the eleven different types of control block. The set of eleven 8-bit patterns constitute a rate-4/8 code, with Hamming distance 4, for indicating the eleven different types of control block.
Modulation encoded blocks are typically subject to various additional processing stages, such as scrambling, compression encoding and error correction processing, before transmission. Scrambling is a common process for improving transmission characteristics whereby each bit in an input block is combined with one or more other bits (whose values are generated continuously in a time-dependent manner, e.g., from previously scrambled bits) to produce a corresponding bit in the resulting scrambled block. Compression encoding (often referred to as “transcoding”) is performed in order to increase data rates. In the systems described above, for example, rate-64/66 modulation coding is performed in the Physical Coding Sublayer (PCS) of the physical layer of the OSI (Open Systems Interconnection) reference model. Within this PCS layer, modulation encoded blocks are subject to a scrambling process illustrated in FIG. 2 of the accompanying drawings. The sequence of data or control blocks forming the payloads of successive 66-bit encoded blocks provides the input to the scrambler, the 2-bit sync headers being removed before scrambling. The resulting preliminary blocks at the scrambler input have 64 bits, p0, p1, . . . , p63. The input sequence of preliminary blocks is scrambled to produce a corresponding sequence of scrambled blocks, each with 64 bits s0, s1, . . . , s63. The scrambler is a self-synchronizing scrambler defined in the IEEE 802.3ba standard and shown in FIG. 3 of the accompanying drawings. This scrambler, which runs continuously, includes a 58-bit shift register S0 to S57 in a feedback arrangement with two modulo-2 adders (labeled “+” in the figure). After scrambling, the 2-bit sync header is added to each scrambled block to produce the transmit block. The resulting stream of transmit blocks is then further processed in the PCS sublayer before forwarding to the Reed-Solomon (RS) forward error correction (FEC) sublayer RS-FEC. For example, the blocks are distributed over multiple channels, or “lanes”, after insertion of alignment markers for block recovery at the receiver.
Transcoding in the above systems is performed in the RS-FEC sublayer. The transcoding process transforms a group of N data or control blocks into a single encoded output block. For instance, N 66-bit blocks generated with the aforementioned rate-64/66 modulation code may be converted into a single (N*64+L)-bit block. Note that if L<2N, this transcoding process always results in compression. Such a transcoding process is described in our copending U.S. patent application Ser. No. 13/765,382, filed Feb. 12, 2013. One embodiment provides a 64b66b to 256b257b transcoding scheme which is used in the RS-FEC sublayer defined by IEEE Ethernet task force 802.3bj for full-duplex 100 Gb/s data transmission. This scheme encodes a sequence of N=4 rate-64/66 modulation coded blocks into a single 257-bit output block. The 2-bit sync headers of the 66-bit input blocks are deleted in the encoding process, along with the second 4-bit nibble of the block-type field of the first control block (if any) in the four-block sequence. Due to redundancy in the block-type field, the remaining block-type field bits are sufficient in themselves to indicate control block type. This redundancy in the block-type field permits recovery of the entire block-type field by mapping the remaining block-type field bits to the missing bits during the corresponding decoding process (referred to herein as “inverse transcoding”) at the receiver. A 5-bit header is then added to the sequence. This includes a 4-bit position indicator to indicate the position of any control blocks in the block order of the four-block sequence, and a single bit to indicate whether or not the encoded output block contains any control blocks.
The transcoding schemes described in co-pending U.S. application Ser. No. 13/765,382, filed Feb. 12, 2013, preserve the order of data and control blocks in the input block sequence. Other known transcoding schemes reshuffle (rearrange) the order of the incoming blocks. For example, a 64b66b to 512b514b transcoding scheme is described in “Bit-Error-Tolerant (512*N)B/(513*N+1)B Code for 40 Gb/s and 100 Gb/s Ethernet Transport”, Teshima et al., IEEE Infocom Workshops 2008. Control blocks in a sequence of N=8 rate-64/66 modulation coded input blocks are grouped together at the start of the encoded output block, after a 2-bit header. The 2-bit sync headers of the 66-bit input blocks are deleted, and the entire block-type field of each control block is replaced by a new 8-bit field. This includes a 4-bit encoding indicating control block type, and a 3-bit position field indicating the original position of the control block in the 8-block input sequence. The position field allows block order to be restored during inverse transcoding, and the 4-bit encoding permits identification of control block type and hence recovery of the block type field. A related 64b66b to 1024b1027b transcoding scheme is also described. Similar transcoding schemes based on reshuffling control blocks to the start of the encoded block have been described for 64b66b to 256b257b transcoding and 64b66b to 512b513b transcoding.
The transcoding processes described above exploit redundancy in the block-type field of control blocks, permitting deletion in the transcoder of certain block-type field bits which can be regenerated from the encoded blocks at the receiver. In order to do this, however, the input block sequence, which is received in scrambled form from the PCS sublayer, is first descrambled in the RS-FEC sublayer before supply to the transcoder. This results in a sublayer architecture which is shown in FIG. 4A, for the transmitter (TX) side, and in FIG. 4b for receiver (RX) side. (These figures show the architecture for non-return-to-zero signaling, a binary pulse amplitude modulation scheme, but the same basic steps are required in the alternative architecture for other pulse amplitude modulation signaling schemes). At the transmitter, scrambled blocks distributed over lanes from the PCS sublayer are received by the RS-FEC sublayer. The blocks are first aligned and alignment markers removed. The scrambled blocks are then descrambled for supply to the transcoder. After transcoding the blocks must be rescrambled, and alignment markers (mapped from the alignment function at the input) are reinserted. Error correction processing is then performed by an RS FEC encoder, and the resulting output words are distributed over lanes for onward transmission. This structure necessitates a corresponding structure at the receiver as shown in FIG. 4B. In addition to the resulting complex sub-layer structure, the use of a self-synchronizing scrambler as described above requires use of such a scrambler following inverse transcoding in the receiver. This is undesirable due to the problem of error multiplication: a single bit error at the input of the RX self-synchronizing scrambler multiplies to infinitely many errors. Although the descrambler in the RX PCS sublayer regenerates the possibly-erroneous original sequence at the RX scrambler input, massive error multiplication within a sublayer is undesirable in an architecture that cleanly separates the sublayers.